| I prefer ASCII-Mail, but you can also send me NeXT-Mail |
From: MKK2@psuvm.psu.edu
Date: Tue, 8 Sep 92 15:50 EDT
Subject: Your mission, should you choose to accept it. . .
To: gnu-objc@prep.ai.mit.edu
This group could do and could be a lot of different things. It seems to me
that some discussion of a "mission" are in order. If we can agree on
some long range goals, then we can try to form teams that will work on
the first steps towards those goals.
The long range goal still seems to be pretty general, like "Create lots
of useful Obj-C Free software." That's OK by me, at this point.
As a first step in that direction, let me propose an immediate bojective:
Create a set of classes that implement the usual data structures that is
general, extensible, reusable, and similar to other similar sets.
Since I am working in NeXTstep, one obvious bias I have is toward the
already existing Object, Storage, List, and HashTable. I'd like to see
subclasses of these built along the lines of Smalltalk for Bags, Sets,
Queues, etc etc etc. Along the way, I hope that others would take on the
task of making clones of the NeXTstep common classes, so that none NeXT
programmers and NeXT programmers could write common code.
just a thought.
Date: Thu, 10 Sep 1992 15:12:40 -0700
From: Bruce Nilo <bruce@ictv.com>
To: gnu-objc@prep.ai.mit.edu
Subject: Re: Your mission, should you choose to accept it. . .
[moved PROTOCOL IMPROVEMENT]
[moved ERROR HANDLING]
[moved BETTER RUNTIME SUPPORT FOR MULTI-THREADED PROGRAMS]
GENERAL DATA STRUCTURES:
NeXT provides a minimal set of data structures. They often do not
handle conceivable errors, and do not specify protocols which they
follow. (In addition they are often curiously named. For example List
is not a traditional list. In more traditional circles it would be
referred to as a dynamic array. Why not call it that?)
When building a container class library reasonable interfaces
(protocols) should be defined, shared, and consistently used
throughout. Errors should be reliably reported. (Perhaps class names
could be based on implementation as opposed to interface?) Some useful
data structures which come to mind include B-Trees, Red Black Trees,
AVL trees, priority queues (or heaps) Lists, Stacks, and Queues. In
general it would be nice to know the algorithms used to manage these
data structures (or at least their worst case time/space complexity
bounds.) The reason for this is that hiding behind any interface can
be a >= N**2 implementation.
- Bruce D. Nilo
VP Software Systems
ICTV
Date: Thu, 10 Sep 92 11:31:08 EDT
From: dstrout@darpa.mil (David Strout)
Received: by NeXT Mailer (1.82)
To: gnu-objc@prep.ai.mit.edu
Subject: What must we have, what can wait?
Well, I guess it's time to throw my 2 cents in....
My goal for the project is to see a baseline set of objects that behave identically between the GNU system and the NeXT system. What I hope for is that a program written under GNU ObjC would compile & run under NeXT. Going the other way (NeXT -> GNU) does not seem as necessary to me. It may not be appropriate, or even desirable, for the GNU system to try and replicate every feature of NeXTStep. We could lose alot of time trying implement Speaker / Listener while there was yet work to be done on Window, for example.
Suggestion 1: Someone (or a small group) identify the minimum set of objects that GNU needs to support to do useful application development. I believe that these objects should be chosen from what NeXT supplies. NeXT's specs are easily available, clear, and designed to work together. Choosing a few objects from NeXT, a few from Stepstone, a few from SmallTalk, etc. will multiply the time to completion by a large factor, due to the extra integration work required.
Suggestion 2: Delay thoughts of an InterfaceBuilder-like program. That can come after we have a basic appkit. It's great to be able to drag a button off of a palette, but it's just as effective to say myButton=[[Button alloc] init] in a piece of code.
In essence, what I am saying is to avoid chrome for the moment and concentrate on that subset of features that are required to make an useful system. There is alot of creativity in this group, alot of enthusiasm, and alot of skill. I am simply advocating that we try to temper that with some discipline and restraint. There will be a time for every idea, no doubt. Its just that careful thought needs to go into the order in which the ideas are pursued.
dave.
--
Dave Strout
dstrout@darpa.mil
NeXTMail preferred
703/243-9467
/* Any opinions expressed are strictly mine,
* Not ISI's, DARPA's, or the US Gov's.
*/
Thompson's Rule for First Time Telescope Makers:
It is faster to make a four-inch mirror then a six-inch mirror than to make a six-inch mirror.
Date: Thu, 10 Sep 92 17:18:49 -0500
From: jr@alpo.media.com (J.R. Jesson)
To: gnu-objc@prep.ai.mit.edu
Subject: Re: Organizing groups
MKK2@psuvm.psu.edu writes:
> here are some thoughts on organizing this effort, or, for that matter,
> determining what this effort is going to be, in the first part.
>
> PROJECTS
>
> We have to reach agreement on what the initial projects will be. For
> example, I suggest these two:
>
> 1. EXTEND NeXTstep COMMON CLASSES. NeXT includes Object, List, Storage,
> and HashTable. NeXT programmers need "the rest". Bag, Set, OrderedList,
> Stack, Queue, Heap, etc etc etc
>
I've found NeXT's foundation class definitions to be grossly
anemic. Why use NeXT as the sole model for cloning classes?
Stepstone, the progenitor of Objective-C, has a good basic class
set. (gee - I wonder if anyone has asked them to contribute ICpak101
to the effort? No - you first!) Or maybe we could use a Smalltalk'ish
set of basic classes. The point is not to look too closely at NeXT -
I'm much more of an objective-C fan than I am a NeXT fan (ok, so I
have a NeXT on my desk - so what?).
jr
From: MKK2@psuvm.psu.edu
Date: Fri, 11 Sep 92 10:38 EDT
Subject: Re: general direction
To: gnu-objc@prep.ai.mit.edu
I can appreciate the goals of the FSF, an organization for which I have
loooong had the utmost respect and admiration.
Even so, I want to make one small pitch for an approach that might smack of
being too dependent on NeXTstep.
All NeXTstep classes are descendents of Object. Object provides some important
services that many, if not all, NeXT programs avail themselves of. For
One example, Object is where some basic archiving and unarchiving capabilities
reside, so that any class can be archived with a simple NXWriteObject() call.
(Omitting all the details, of course. You get the idea.)
So, for new classes like SortedList, PriorityQueue, and whatever to be fully
useful to a NeXT programmer, they should also inherit from Object. This
does make them NeXTstep "dependent" in a sense, which is *bad*. My hope is
that we can create a GnuObject that is sufficiently compatible with NeXT's
Object so that both NeXT and non-NeXT GNU OBJ-C programmers can use them
in the same way, with perhaps a few #ifdef's making the whole thing
transparent.
I don't know much about the Obj-C runtime. Perhaps Object is actually OBJ-C
|> > here are some thoughts on organizing this effort, or, for that
|> matter,
|> > determining what this effort is going to be, in the first part.
|> >
|>
|> > PROJECTS
|> >
|>
|> > We have to reach agreement on what the initial projects will be. For
|> > example, I suggest these two:
|> >
|>
|> > 1. EXTEND NeXTstep COMMON CLASSES. NeXT includes Object, List, Storage
|> > and HashTable.
(NX)StringTable, (NX)StreamTable
|> > NeXT programmers need "the rest". Bag, Set, OrderedList,
|> > Stack, Queue, Heap, etc etc etc
|> >
|>
|>
|> I've found NeXT's foundation class definitions to be grossly
|> anemic. Why use NeXT as the sole model for cloning classes?
I agree that NeXT's Obj-C should not be the 'sole model' for paterning
the Class Library after. I do however think that it would be useful
to provide some NeXT(STEP) backwards compatibility because that is
where the current largest installed base of (possibly free) objects is.
I think a good way to do this would be to provide the BC ability in a
category that can be included or not.
Someone else mentioned that NeXT's List Class is what you would normally
think of as a List, it is actually a DynamicArray (and a DynamicArray
of IDs at that). So, I could see a DynamicArray object (which is kindof
like NeXT's Storage). With a List.[hm] and Storage.[hm] files that are
actually categories of DynamicArray, allowing Source Code compatibility
to some code someone has already written on the NeXT.
Of course, if the person who writes a Class (DynArray), doesn't know
much/anything about the NeXT then s/he/it could leave it to someone else
to implement.
I'm not first-hand-familiar with Stepstone, but the same thing could
possibly be done for their interfaces as well.
(I also think this way the Classes could be 'designed from scratch' and
if any legalities arose from providing BC interfaces to objects, they
could be yanked from the distribution and we would still have functional
objects.)
|> Stepstone, the progenitor of Objective-C, has a good basic class
|> set. (gee - I wonder if anyone has asked them to contribute ICpak101
|> to the effort? No - you first!) Or maybe we could use a Smalltalk'ish
No - you first.
|> set of basic classes. The point is not to look too closely at NeXT -
|>
|> jr
Bill S.
Date: Fri, 11 Sep 92 10:42:34 EDT
From: dstrout@darpa.mil (David Strout)
To: gnu-objc@prep.ai.mit.edu
Subject: Re: design decisions
MKK2@psuvm.psu.edu writes:
> 1. EXTEND NeXTstep COMMON CLASSES. NeXT includes
> Object, List, Storage, and HashTable. NeXT programmers
> need "the rest". Bag, Set, OrderedList, Stack, Queue,
> Heap, etc etc etc
>
Well, I must disagree. I seem to get by just fine without any of "the rest" of those classes. I am not saying that they wouldn't be useful, just that they are not required for application development. Seems to me that getting a very basic set of NeXTStep compatible objects running ought to take priority over extentions or additions. I'm not claiming that NeXTStep is complete, or that it offers everything you could ever want. But it is a complete and functional system. Essentially, if something is not in NeXTStep, I feel we need to ask a couple of questions before we conclude that it's a "must have".
1.) How did NeXT live without it?
2.) Is there a more general class that can be abused to do what we want or that provides 90% functionality?
I don't want to imply that classes other than what NeXT supplies are bad, I just want to suggest that maybe they should be delayed until the foundation is set is soild.
dave.
--
Dave Strout
dstrout@darpa.mil
NeXTMail preferred
703/243-9467
/* Any opinions expressed are strictly mine,
* Not ISI's, DARPA's, or the US Gov's.
*/
"If you have too many special cases, you're doing it wrong"
Date: Fri, 11 Sep 1992 12:55:55 EDT
From: gdb0@lehigh.edu (GLENN BLANK)
Subject: Automatic input/output, persistence
To: gnu-objc@prep.ai.mit.edu
A key difference between the NeXT and StepStone foundation class
libraries is the latter supports a much more convenient scheme
for storing objects to and reading them back from files.
The NeXT version, as I understand it (I don't have a NeXT; I have
a Sun running Stepstone's version), only supports what I would call
"semi-automatic" input/output--that is, the implementor of each subclass
must implement methods to archive objects of this subclass. The
Stepstone library does not require any new implementation at all. If
your object is a subclass of Stepstone's Object, it automatically
inherits Object's hooks automatic input/output--providing you
explicitly link in the relevant code.
Semi-automatic input/output is about all C++ libraries can do:
since C++ does not support metaclass information at run-time.
Automatic input/output is one of the very nice features of Smalltalk,
which Objective-C can imitate, because it does support metaclasses,
and so can know how to allocate instances of some class when it
reads one from a file. Needless to say, automatic input/output
can save a lot of work, especially in continually evolving
applications like mine. I'd sure like to see support for it in the
GNU version, rather than settle for the NeXT interface.
May I point out that automatic input/output also opens the door
for object persistence. This need not imply a full blown OODB,
with query capabilities, etc. The StepStone implementation stores
one whole object per file--the object can be arbitrarily complex,
e.g., the filer will handle vanilla C instance variables,
chase object ids, yet avoid duplicating objects to which there
is more than one pointer. A more flexible design might allow one
to store/access many objects per file.
Date: Fri, 11 Sep 1992 14:21:25 EDT
From: gdb0@lehigh.edu (GLENN BLANK)
Subject: re: automatic input/output, persistence
To: gnu-objc@prep.ai.mit.edu
From: liberte@ncsa.uiuc.edu (Daniel LaLiberte)
>Does the automatic input/output let subclasses override the input/output
>so that different info may be read/written? This would provide the
>best of both automatic and manual mechanisms.
Stepstone's reference manual says that you can substitute your own
Filer class, or have several alternatives, for the AsciiFiler class
which provides their automatic I/O support. Your alternative
Filer class must then implement methods which responds to the
appropriate messages. Note that this doesn't spread the
implementation of I/O across all the client classes.
Another nice feature of AsciiFiler is that it allows you to
show the contents of any object at run-time--very handy
for debugging! Does the NeXT version offer anything comparable?
>dan
glenn
Date: Tue, 15 Sep 92 09:14:27 -0400
From: athan@object.com (Andrew C . Athan)
To: uunet!stb.info.com!michael@uunet.uu.net (Michael Gersten)
Subject: Re: Idea for class structure.
Cc: gnu-objc@prep.ai.mit.edu
> "fakeobject" classes cannot be used...
My first reaction to this is that it seems like an add-hoc solution .. a "hack" to get things working. I think solving this is more of a design issue than anything else. The problem can be solved in at least four ways without compiler support (see below). Now, I'm not saying some of these ways aren't hacks themselves, but they have the advantage that they don't involve changing the compiler. The least desirable method is (2).
(1) design your container class better, so that -it- does not call new but instead gets passed an id in which it uses as is.
(2) Pass in an instance of a class that forwards all messages to some given object, except for "new" which returns the object itself.
(3) "UniqueString" instances should respond to everything the the class object of "UniqueString" does (perhaps simply by forwarding to their class).
(4) "UniqueString" class should responds to new/alloc/allocFromZone by returning "self" and should overide "free" to "do nothing." (which class objects do already, no?)
Here's how you might use a "forwarding" class in the case where you cannot use solutions (1),(3) or (4) because you don't have the source code [FakeNewClass can be made much simpler if you know ahead of time the set of methods that might ever be called on it. In fact, if you know it needs only "new" than all you need are the init and new methods implemented in Forwarder below]:
[forwarder free]; //If you're sure it doesn't need it any more
...
}
@interface Forwarder:Object
{
id someObject;
}
- initWithObject:obj;
- setObject:obj;
- new;
- forward:(SEL)aSelector:(marg_list)marg;
/* Also should implement all Object methods by forwarding to someClass */
@end
@implementation FakeNewClass
- initWithObject:obj
{
[super init];
[self setObject:obj];
return self;
}
- setObject:obj
{
someObject=obj;
return self;
}
- new
{
return someObject;
}
- forward:(SEL)aSelector:(marg_list)marg
{
if([someObject respondsTo:aSelector]){
return [someObject performv:aSelector:marg];
} else {
[self doesNotRespondTo:aSelector]; //or whatever; I forget the method name
}
}
/* Implement rest of Object methods so that they forward to someObject */
@end
Enjoy!
Andrew Athan
Date: Wed, 16 Sep 92 09:47 PDT
From: michael@stb.info.com (Michael Gersten)
To: ucla-cs!prep.ai.mit.edu!gnu-objc@cs.ucla.edu
Subject: re: Idea for class structure.
Perhaps I didn't make it clear before. This is not an ad hoc proposal.
Right now a class is at best an object of class 'Object'. This implies that there is no behavior specific to a class object that is not also true of all other objects.
The way that new classes are added to the inheritance hierarchy is buried in the dynamic loading routines.
There is no way to implement meta-class messages, such as "return a list of all the selectors that class X resonds to", without sticking it into class Object and having to check the passed arguments.
Here's some more comments that I've sent to someone else. It might do a better job of explaining things:
Date: Tue, 15 Sep 92 11:30:18 PDT
From: michael (To: ucla-cs!jupiter.fnbc.com!billb)
To: ucla-cs!jupiter.fnbc.com!billb
Subject: Clarification
Right now a class is an object of type 'Object'.
Why not make it an object of type 'Classes'?
The class 'Classes' is where class specific behavior would be placed. And, as 'Classes' is a class, it could have class methods as well.
Examples: You could re-arrange/add to the inheritence hierarchy at run time by sending an 'inherit' message to an object of type 'Classes'; this would be handled by a method implemented in 'Classes' as an object (not factory) method. A new class would be created by sending a 'new' message to 'Classes' (the +new method); this would return a generic new class.
At the same time, when you declare 'Foo' to be a class, you are saying that 'Foo' is an object of type 'Classes', and 'FooClass' is a corresponding object of type 'MetaClasses'. The difference between these two would be that one would describe the behavior of classes -- such as getting a list of methods that are implemented, etc., the other would be for 'abstract superclass' behavior of classes. Only difference I can think of right now is that 'MetaClasses' would define a -new method that returns the appropriate existing class object -- this would let you say '[Foo new]' to get a new foo object (which could be implemented as Object:+new), or '[FooClass new]' to get a copy of the object of type 'Classes' that corresponds to Foo (and would be the same as '[Foo self]') (this would be implemented as MetaClasses:-new), or you could ask for a new class structure that you would then modify to create a new class (which is currently hidden inside of the dynamic loading primitives) (and would be implemented by either Classes:+new or MetaClasses:+new).
Note that if you want to have dynamic code (such as smalltalk or lisp), you need a way to have dynamic hierarchies. After all, whats to stop someone from designing a system where you have an incremental compiler, and the compiler and debugger are part of the execution environment, and after you define a class it is now part of the compilation environment? (And there is little or no distinction between the compilation environment and the run time environment).
Michael
--
Michael Gersten michael@stb.info.com
HELLO! I'm a signature virus! Join in the fun and copy me into yours!
This is in reference to all of the discussion on the differences between object archiving on NeXT and Stepstone. Why not just write an equivalent to Stepstone's default AsciiFiler class using @encode of the class to archive? The resulting string could be processed, byte by bye, with default behaviours per data type. This is probably what Stepstone is basically doing, anyway.
-chuck
From: MKK2@psuvm.psu.edu
Date: Thu, 1 Oct 92 16:50 EDT
Subject: libg++ info wanted
To: gnu-objc@prep.ai.mit.edu
I'd like to take a look at the classes in libg++. At this point I need
to know what the classes are, and what methods are implemented. If
I could find a discussion of design decisions, that would be great, too.
I know that the .tar.Z files are on prep.ai.mit.edu, but getting FTP'd
files through this ebcdic mainframe and a 2400bps pipeline is a real
hassle, so I was wondering if someone could point me to a printed version
of the docs, or offer to email me the man pages, or whatever.
